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Remarks 

Claims 1-7 are pending in this application. Claims 1-7 stand finally rejected by Berg et al. 
(U.S. Patent Publication No. 2002/0188481 ; hereafter "Berg - ) under 35 U.S.C, § 102(e). 

Before addressing the present rejections, a brief summary of the prosecution history is 
provided, tn the office actions mailed 02/07/2005 and 07/15/2005, claims 1-6 were rejected 
under 1 02(e) over Harif (US 20Q2/0087881 ) which disclosed inter alia use of digital signatures. 
Applicants' responded in part by explaining that digital identity of the present invention is different 
from digital signatures and digital certificates because it does not involve installing/downloading 
software/program instructions (see page 5 of remarks filed 08/30/2006). Subsequently, in the 
non-final office action mailed 09/30/06, the arguments were deemed persuasive and the rejection 
under Harif was accordingly withdrawn. However at the same time, a new 1 02(e) rejection was 
made in view of newly discovered art to BrachtJ (US 4,747,050) which required inter afia personal 
identity cards. Applicants' responded on 11/28/2005 with an amendment and remarks stating in 
part that according to me present invention, the User does not require a personal identity card tn 
order to use digital identity. Subsequently, in the office action mailed 02/17/2006. the arguments 
were deemed persuasive and the rejection under Brachtl was accordingly withdrawn. However at 
the same time, new rejections under 102(e) and 103(a) were made in view of Teper et: al. (US 
5,81 5,665), which required inter alia users to download/install client software components, and 
Aziz (US 5,732,137). In the response dated 04/06/2006, applicants* amended the claims and 
provided remarks to explicitly explain that the User does not require received software (e.g., in 
the form of proprietary software, digital certificates, etc) to use digital identity (see, pages 4-5 of 
the remarks filed 04/06/2006; see ateo, page 5 of the remarks filed 08/30/2005). In the latest 
office action mailed 06/20/2006, the arguments were deemed persuasive and the rejections 
under Teper and Aziz were accordingly withdrawn. However, at the same time, a new final 
rejection 'as necessitated by applicants' amendment was made under 102(e) in view of Berg et 
al. (US 2002/0188481) which uses Inter alia digital certificates (which applicants' distinguished 
from previously). In view of the above summary and the following remarks, applicants 1 
respectfully request reconsideration and withdraw of the final office action. 

The prior art rejections are addressed betow. 

Refactions under » U-3X. & 102Te) 

in the Final Office Action mailed 06/20/2006. the Office rejected claims 1-7 under 35 USC 
§ 102(e) as being anticipated by Berg. Applicant respectfully traverses this rejection and submits 
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thatttecftsck»uretf 
reasons. 

Berg is generaHy directed toward providing insurance coverage for online transactions to 
reduce risks, such as fraud, associated with a web-based marketplace, Specifically, Berg 
generates and pro>^ea a financial product which can provide insurance coverage "guaranteeing* 
(a?., finanriaBy) the identity or financial viability of a user (or trading counterpart) andtor the 
completion of a transaction with a trading counterpart [0002]. The insurance coverage provides, 
in exchange for payment of a premium, assurance against e.g., rnistdentification of. a trading party 
100123. [0033}. Thus, rather than authenticating or positively identifying a User, Berg provides an 
online insurance prod uct that compensates for the possibiBty of user mfektentificaton, inability to 
pay for a transaction, etc 

The system of Berg discloses various "entities' including: users (20) (e.g M . marketplaces, 
buyers, sellers); a JV Authority (30); a Registration Authority (40); a Credential Issuing Authority 
(50), etc* (see, Figure 1), In operation, users (20) initially submit identifying information to a Joint 
Venture (JV) Authority (30)- The JV Authority (30) processes the input information with 
information contained in a database of business information providers for verification [0007], 
$0831 The JV authority (30) may itself be a business information provider (e.g., Dun & 
Bradstreet) that provides business, financial, and/or quality assurance information, in addition, 
the business information provider may provide identity and financial information such as: contact 
information, financial risk assessment, financial viability, credit-worthiness, credit score, 
profitability, etc [0005J, 10006]. After verification is complete, the JV Authority (30) sends 
information regarding the user (20) to a Registration Authority (40) that can register the verified 
user (20) and request security credentials, such as a digital certificate, from a Credential Issuing 
Authority (50) [0007], [0017]. 

Regarding claim 1 and similarly rejected claim 5 k the office action states on page 3: 
"where the JV authority corresponds to the recited central-entity' Applicants' respectfully 
disagree. Unlike the Central-Entity of the present invention, the JV Authority does not perform 
authentication or a User based on digital identity. Rather, the JV Authority (30) Verifies* 
identity and/or financial viabHfty of trading counterparts or users by processing identifying user 
information in conjunction with business information obtained from business information 
providers. Such information corresponds to e.g., contact information, profitability, etc. However, 
a user cannot be positively identified by the JV Authority as a result of comparing information 
inputted by the user with obtained/purchased business information. This is because such 
information can be easily obtained, intercepted, stolen or guessed by others, and therefore 
cannot provide positive proof as to the user's identity. Instead, the purpose behind the 
verification of Berg is to provide a risk assessment as to whether the user will be able to pay for a 
transaction. (It is also noted that nowhere does Berg mention authentication). Thus, Berg does 
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not teach where the JV Authority authenticates or positively identifies users - not to mention 
based on digital identity. 

Berg atso does not disclose whereby the External-Entity may forward digital identity 
received from a User to the CentrekEntity for authentication. Contrary to the present 
invention, nowhere does Berg disclose or suggest that the seller is able to receive digital identity 
from the User. Instead, Berg discloses that both buyers and sellers submit their security 
credentials to an intermediate marketplace [0034]. However, such a marketplace introduces a 
large number of additional entities, intensifying the possibility of user information being 
intercepted, spoofed, and/or misappropriated. Advantageously, the present invention avoids this 
problem by enabling "digital identity* to be securely provided to the External-Entity without 
compromising the User's personal and/or confidential Information. 

Moreover. Berg fails to teach wherein the User does not require use of software 
received from the Central-Entity to employ digital Identity, Berg discloses that a user 
receives security credentials, or unique identifiers (such as digital certificates) from the 
Registration Authority [0007]. However, digital certificates comprise files that are downloaded 
and/or installed on a user's computer, (It fe also appreciated that "software" is conventionally 
understood to be a set of computer-executable instructions.) In paragraphs [0007] and [0011], 
Berg even states that the digital certificates may be "downloaded and temporarily stored on any 
computer being used by a user to verify identity and to facilitate subsequent interaction with 
trading counterparts (emphasis added). Thus, users would be required to download/install 
software with the digital certificates of Berg. Conversely with the present invention, Users may 
employ digital identity without first being required to install/download software (eg,, in the form of 
digital certificates, proprietary software, etc.) received from the Central-Entity. 

It appears that the Office may not fully understand the nature of digital certificates by 
associating tfie digital certificates of Berg with "digital identity" of the present invention. Although 
applicants' distinguished between digital certificates and "digital identity" on page 5 of the remarks 
filed 08/30/200$, the Office contffiues to apply prior art that relies upon digital certificates. 
Therefore, In response to the Final Office Action, two publications 

(www.computinq.vt.adu/securitv and viruses/certificatee/index.html: and "United States Patent 
and Trademark Office Public Key Infrastructure Subscriber Agreement," version 30) are included 
in Appendix A at the end of this communication to illustrate that digital certificates Involve users 
receiving software from a Central-Entity to download/install on their computers - contrary to the 
present invention as claimed. 

As an alternative to digital certificates. Berg very briefly mentions that the unique Identifier 
may also refer to user name, password or alphanumeric Identifier [0037]. However, "digital 
identity* is not the same as a password, user name or alphanumeric identifier. The problem with 
user names and passwords, etc is that they are highly susceptible to being stolen, intercepted, or 
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guessed, and are thus not convfenfonaBy considered to be mfiabte means in themselves for 
authenticating, or positively identifying, a user. Advantageously, "digital identity* provides more 
security than just a password, user name or alphanumeric identifier. For example, according to 
one embodiment digital identity includes a SecureCode and other information such as UserName 
and is entirely non-predictable such that the User's personal information remains highly secure. 
Because of this, the External-Entity may receive digital identity from the User wShout their 
personals confidential information being compromised. This is not so with the passwords or 
user names of Besg. Transmission of passwords or user names to the External-Entity (in place of 
digital idenfity). would render the present invention inoperable and/or pointless as the User's 
personal or confidential information would be exposed and security compromised. 

Furthermore, the participants of Berg are limited to those registered In the marketplace. 
In situations where External-Entities (e.g. , government agencies, universities and financial 
institutions}, do not participate in such a marketplace, the system of Berg does not offer any 
solution or added-value Examples of identity authentication in relation to such entities include 
where: the customer applies for government services over the internet; applies to vote online; 
applies for mortgage online; applies for a new credit card online, etc. In these examples, the 
ExtemalrEntffles do not sen negotiable products and therefore cannot participate in Berg's 
marketplace. Thus, Berg's marketplace would not provide any value to such entities. 

In an offline wartd, businesses authenticate customers 1 identity by looking at the 
customers driver's license or identity card. In the online world, however, businesses currently do 
not have a simple or cost effective alternative to secu rely authenticate a user's on line identity. 
Systems such as those taught by Berg are usually too complicated to reach the mass market 
One reason for this being that the process of downloading and Installing digital certificates is too 
time-consuming andfor burdensome. For example, users may not be computer-literate enough to 
know how to download and install a digital certificate. Moreover, the transaction may comprise a 
small, one-time transaction that doesn't justify the amount of effort involved in obtaining a digital 
certificate. Alternate authentication efforts using smart cards have also failed to take off since 
these introduce their own set of prohibitive implementation costs and burdens. Thus, ft contrast 
to digital certificates and smart cards, digital identity of the present invention ft Is the 
authentication gap that exists in the online world today by. providing a secure and cost effective 
solution that is easier to implement and use. Moreover, because digital identity increases trust in 
transactions, businesses can experience reduced risk and increased revenue as a result 

To anticipate a claim, the reference must teach every element of the claim: la] dawn is 
anticipated only if each and every element as set forth in the claim is found, either expressly or 
inherently described, in a single prior art reference.* VenJegaaJ Bros. v. Union Oil Co. of 
California, 814 R2d 628, 631. 2 USPQ2d 1051, 1053 (Fed- Cir. 1987). See MPEP 2131. 
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However, Berg fails to disclose each aid every claimed limftafori as evidenced m toe above 
discussion regarding simBeuffy rejected claims 1 and 5. Accordingly. Applicants' submit that 
claims 1 and 5 and.thetr dependents are allowable over the prior art and request that the current 
rejection be withdrawn. 



Applicants' respectfully request reconsideration of tbe claim rejections based on the 
above amendments and remarks- It is believed that a full and complete response has been made 
to tbe outstanding Office Action* and as such, the present application is in condition for 
allowance If Bfce examiner believes that personal communicatiorv will expedite prosecution of thie 
application, the Examiner is invited to telephone the undesigned at<571) 228-2938. 



Conclusion 




Respectfully, submitted, 
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Search: 



computing.vt.edu 

Home J Services A-Z | Help A Tutorials 

You Are Here: yorne > Secmtyjtyjmses > Digital certificates 

Digital Certificates at Virginia 
Tech 

To promote the use of digital certificates, the e-Provisfoning Croup has 
established the Virginia Tec h Ceiqficatj^ (VTCA) to provide a 

digital cernftcate service to tne campus community. The VTCA is a service of 
Virginia Tech that is responsible for issuing and managing digital certificates 
and public keys for Virginia Tech affiliated entities. The VTCA guarantees the 
identity and the authenticity of the entitles to which it issues digital 
certificates by using approved polides and procedures outlined in the Virginia 
TeciXJiQaCer^^ (PDF, 152 KB) document- 

Contents 

• Introduction 

• VLrgini a Tech Certifi cate C omponents 
o For Des ktop Users 

■ ROQl-Certiflca te Do wnload an d Insta llation 

■ Personal Digital C ertific ates 

■ Middleware Certificate 

■ Server Certificate 

• General Documen tation 

o £re,quenjay_A$ked Que^jong 

o Glossary, of Terms 

o PelLcjes 

o Presentations 

• Obtaining Further As sistance 



Appendi x A - Document 1 



Directory Tools 

• People Search 

• PlDjnfpnnation 

Related Tasks 

• EDju.sa.ge Requirements 
(PDF, 15 KB) 

• Request|ng w E_Mp_Serv|ce 

Related Departments 

• Information JR^purce 
Managemenf ORMJ " 



Introduction 

The VTCA is the core of the Virginia Tech PuWic Key Infrastructure (PKJ) 
which is a set of comprehensive system policies, procedures, people, and 
technologies working together to allow secure and confidential 
communication between Internet users, including the ability to issue, 
maintain, and revoke digital certificates. To reinforce security measures , 
digital certificates L are digitally signed by a third party known as a certificatio n 
authority PKI provides the critical dement of trust In electronic transactions 
as wdl as communications. It provides a means for relying parties to know 
that another individual's or entity's public key actually belongs to that 
individual or entity. 
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Digital certificates provide secure connections to electronic services and can 
be issued to organizations and devices in addition to people. A Certification 
Authority Is a trusted third party that verifies the identity of an entity 
registering for a digital certificate. Once a Certification Authority 
authenticates the requesting entity's identity, It issues a digital certificate to 
the requesting entity binding Ms or her identity to a public key. All digital 
certificates have an explicit start date and an explicit expiration date. Most 
applications check the validity period of a certificate when the digital 
certificate is used. 

For more information about digital certificates, see the following: 

• The Corporation for Research and Educational Networking (CREN)'s 
PKI Resources 

• ftSA Laboratories' Public- Key Cryptography Standards 

• Internet?? CmipcatesjndPKI 



Virginia Tech Certification Authority 
Components 

Digital certificates are electronic identity credentials which use encryption to 
support secure access to a large number of Web services and application* on 
campus. Initially, the VTCA *s Issuing server certificates which are digital 
credentials that reside on a server and set up a secure connection between 
mat server and a client or another server. This secure connection uses PKI 
through either a Secure Sockets Layer (SSL) session or a Transport Layer 
Security (TtS) session. The relationship between PKI and security lies in the 
fed: that the public and private keys can be used for encryption, or hiding the 
content of data as It Is bang transmitted over the network. 

For Desktop Users 

Inorder to realize the security benefits of digital certificates Issued by the 
VTCA, all faculty, staff and students are encouraged to install the VTCA roo t 
certificate on their Web browse rs. After installing the Virginia Tech root 
certificate, applications. using certificates will automatically recognize and 
accept certificates issued by the VTCA. 

If the root certificate is not installed In your Web browser, you may receive 
security warning messages or annoying pop-up windows asking If you trust 
the VTCA when accessing secure services that use VTCA issued certificates. 
Depending on your operating system and browser settings, you may see 
these warning messages every time you access secure servers which are 
using certificates issued by the VTCA. Downloading and installing the VTCA 
root certificate into your browser will help you prevent these recurring 
messages from appearing. 

Eventually, the VTCA service wilt be expanded to issue Personal Digital 
Certificates to faculty, staff and students. 

Root Certi ficate Download and Installat ion 

You wfll need to complete the Installation of the root certificate for each 
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browser you use on your computer and for each different computer. For 
example, you may use one computer at work and another one at home. Also, 
If you are using an cider version of your browser, please upgrade your 
browser before Installing the certificate. 

To install the root certificate, choose one of the following sets of instructions 
according to the browser you use: 

• Firefp* 

• Internet_Exp!prer GJn_Windows 

• HozilJaA.7 

• Nete^pe^S in.Windows 

• Netscape 7J.nJWinclpwsja.nd 

• SafaninJl^ 

Personal Digital Certificates 

In the future, Personal Digital Certificates will be offered to students, faculty, 
and staff for digitally signing documents, personal certificates will be Insta lled 
onto smart cards or tokens and can be used for authenticating to Web ^ 
applications as well as sending or receiving secure e-ma il. The VTCA will play 
an increasingly significant role by providing several important security 
functions including strong digital identity credentials for authentication; 
strong encryption for data communications and storage privacy; digital 
signatures which support non-repudiation of online transactions; and 
document integrity using digital signatures. 



For Server Administrators 
Middleware Certificate 

The Virginia Tech Middleware Application Certfflcatfon Authority (CA) enables 
SSL authentication and encryption for application servers connecting to the 
Virginia Tech ED (Enterprise Directory) authentication and authorization 
services using SSL, orTLS protocols. 

• To review the formal poHcy, refer to the Virginia Teen X.509 
Certificatej^icy (PDF, 152 KB) document. 

• To obtain a Middleware Client Certificate, refer to Requesting, a 
Virginia j^.nM^ 

• To uswOpenSSL, refer to ysjng_OpenS£L to Make a Request for a 
yjrginiaTech Certification, Authority. (VTCA.) Server or Application" * 
certificate- 
Middleware Certificate Profiles: 

• VQrgjnla I^^WdJewa^ (PDF, 89 KB) 

• yirginiaJTe^ Client Certiflcate.Profile (POP, 35 KB) 

• Virginia Jfec^ (PDF, 36 KB}) 

• Virginia Tefb. Middjeware Te5t^Jjent.Certirlcate^rAfile (PDF, 35 KB) 

• Virginia T^Jli^djeware Te^ (PDF, 36 KB) 
For more information on ED, refer to the Enterprise Directory page. 
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Server Certificate 

The Virginia Tech Class 1 Server Certification Authority enables SSL 
authentication and encryption services for networked application servers such 
as Web servers or e-mail. Application servers connecting to Virginia Tech 
computing resources with authentication and authorization services must use 
a digital certificate in order to communicate over a secured communication 
channel using SSL or TLS protocols. 

• To review the formal policy, refer to the Virginia Tech X. 509 
Cei^fica.te Ppljcy (PDF, 152 ICS) document 

• To obtain an SSL Server CA, refer to Requesting, a. Virginia Tech 
CJassjMServerjCe 

• To use OpenSSL, refer to Using OpenSSL _ to. Make_a_Requ.est. /pra 
Vj rcjnje jnech.C&rJt^ Server or App I i cation 
Certificate. 

Server Certificate Profiles: 

• Virginia Tech Class .1. Server CA Profile (PDF, 90 KB) 

• Virginia. T^ch..Class_l. Application Server Profile (PDF, 129 KB) 

• Virginia L Tech^Class J. We.b Server .Profile (PDF, 129 KB) 



General Documentation 

• Frequently Asked Questions 

• Glossary of Terms 

• Policies 

o Virginia Tech PKi Policy Management Authority (PDF, 22 KB) 
o Virginia Tech X.S09 Certificate Policy Document (PDF, 152 KB) 
o CertificatipiLErart^ 

• Proanttttiofl& 

O Client SSU^uthenticabOLn (PPT, 74 KB) 

O DCS5_FalL2004j;r^ (PPT, 398 KB) 

o DC^I^JLZQPJU^ tO„the_VTCA (PPT, 215 

KB) 

o ^e^dtyjrask_Force Presentation^ Strong Authentication 
Technologies (PPT, 7121 KB) 



Obtaining Further Assistance 

If you need help Installing VTCA certificates or have other questions, please 
contact 4heTp by using the Help.Reque^tJ^rrn or by calling (540) 231 -HELP 
(43S7). 



Last updated on August 19, 2005 Re&uest Help | Sit^&ffidhflck | Disclaimer | Privacy, Statement 

c0mputln9.vt.edu is e service of Information Systems and Computing and the Vice President for Information 
Technology. 

<D 2002 - 2005 Virginia Polytechnic institute and State University. 
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United States Patent and Trademark Office 
Public Key Infrastructure 
Subscriber Agreement 

I request that ihelMted States Patent 

^certiScmes (a diflfol sipimg ceflffig ffi aqd a confident iality certificate) 1, in accordance with condhi ons 
stated herein. I have mad and signed the Certificate Action F^"[FrCrFarm-204ZJ requesting issuance of 
public bey certificates to me for doing business with the USPTO. 

f agree that my use and reliance on the USPTO public key certificates is subject to the terms and conditions 
set out below. By signing the Certificate Action Form [FTO Forro-2042] 1 agree to the terms of this 
Subscriber Agreement and to the rates and policies of the USPTO. 

1* Idwitrfieartio* lafcnnatJo* 

a) I warrant that the information 1 submit, as corrected or updated by me periodically, is true and 
complete. 

b) rf any of the mfbrmatton contained in the Certificate Action Form [PTO Farm-2042] changes, I 
agree to update my information within 10 working days via written coimnunication sent to Mail 
Stop EBC, Cc^missioner for Patents PO Box 1450, Alexandria, VA 22313-1450. Tins includes 
loss of right to access a given customer number. 

2- Protection of KrysA 

The USPTO wil 1 not have a copy of ray private key corresponding to the public key contained in the digital 
signing certificate, I understand that the password I establish In the dim software is my responsibility and 
that the password is unknown to the USPTO. Farther, there is no fnechanisrn for the USJTO to find the 
password in the event of a lost password, as in the event of the loss of my private key(s}, the USPTO can, 
at my request, recover only the private key corresponding to the public key contained in the confidentiality 
certificate and authorize the generation of a new digital signing public/private key pair. 

a) 1 agree to keep all password aod private key(s) confidential, and to take all reasonable measures to 
prevent the loss, urwitborized disclosure, modification or use of any password^ and private 
key(s). 1 agree that I will be responsible for these items and that do unauthorized person will have 
access to them. 

b) I agree and acknowledge that, wheji the USrTO issues m 

generate a certificate, the USPTO will keep a copy of rny private key cofrespemding to the public 
key of my confidentiality certificate, and the USPTO will not <£sclosc this key except with my 
consent, or where required by law 



. . Each public key certificate includes the public key of a public/private key pair. Tteidigrtal signing key 

S ir b generated by the subscriber's personal computer via software provided bv the USPTO an d the public 
y becomes part of me digital signing certificate. Only the subscriber holds tber^vatela^cWespc^idmg 
to the public key contained in the digital signing certificate. Bofr the public and private keys of the 
confidenttamy certificate will be generated by b^USFTO Certificate Authority aixl 
channel to the subscriber. The USPTO Certificate Authority will bold a copy of the subscriber's private key 
«>rrespctfidingtotbepu^ 
capability. 



(version 30, April 2005) 
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c) I agree to promptly notify the USPTO i f my passwofoXs) or private key(s) are lost, compromised 
or rendered insecure, or if the nrfbrauttof! contained m my certifk^ request, including address, 
e-mail address, or telephone number, has changed, or becocnes otherwise mconert or uncomplete. 

3. Acceptable Use or Rehaace/Derigiifttioa of Supervised Employee 

I will use my USPTO certificates only for ckctronic cornmunicatiori with the USPTO (e,g^ Patent 
Application foforrnatioo. R&rievai (PAIR) status inquiry, electronic filing, etc). I will use or rely on 
USPTO ratifcatesoaJyjfbrsec^ 
anyone other than the USPTO to rely on them. 

I may designate an employee who may use ray USPTO certificates at wry direction. The designated 
employee may, acting at my direction -and under my control file, a patent application or Jblfowwon papers. 
The employee will use or rery on granted USPTO certificates only for coininunication with the USPTO and 
will not encourage or permit anyone other than the USPTO to rely on them. I understand that 1 am 
responsible for the employee's use of the USPTO certificates. I agree not to use or permit the use of my 
USPTO certificate hi connection with the unauthorized practice of law. If 1 have been granted limited 
recoginticm by the Omce> I agree 
granted. 

I understand that my USPTO certificate will be used to access records and systems on a U.S. Government 
computer system and that unauthorized use or use beyond the purpose authorized may subject me to 
criminal penalties under U-S- Law. 

4. Revocatk>& of Certificates 

a) The U SPTO may revoke my ctttifi cate(s) at any time without prior notice i fi 

i. any of the irrfbrnution 1 supply in my certificate^) request changes; 

u\ the USPTO knows or suspects that my private key (s) has/have been compromised 

iii the private key(s) of the issuing USPTO Certificate Authority has/have been conipromised; 

rv. the signing certificate of the issuing USPTO Certificate Authority is revoked; 

v. I fail to comply with tny obligations under this Agreement; or 

vi. for any other reason the USPTO deems necessary . 

The USPTO wil 1 promptly notify me of the revocation. Such revocation does not affect the authenticity of a 
fransmission made or a message I digitally signed before certificate revocation. 

b) 1 may surrender my certificate(s) at anytime by written submission to the USPTO at: 

Certificate Services Request 
U.S. Patent and TiadVxnark Office 
Mail Stop EBC 
PO Box 1450 

Alexandria, VA 22213-1450 

5. Software use 

I agree to honor any applicable copyright, pan^ crKcerw 

provided to me by the USPTO, and will not tamper with, alter, destroy, nxxiify, reverse engineer, or 
decompile such software in any way. I agree not to use the software for any purpose other than 
commumcation with the USPTO. 



(version 30, April 2005) 
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6. Restriction oil the Export of Pate** Applications: Deemed Export in the 



1 understand tbat technology included in patent applications may be subject to export control regulations, 
and I agree not to use or permit the use of the USPTO certificate tn a manner mat would violate or 
cinuui vent these regulations 

7. Software Export Restrictions 

Cryptographic Software Notice tmdAdmvwUdgematt 

Notice: 

TheUSPTO I>^soirwareirriii^ 

Export Administration Regnlau^ and anyone rera 

may not export the software without a Kcense. 

Acknowledgement 

\ understand that the cryptographic software J receive or download is subject to export controls 
under the Export Administcatioii Regulations and that I may not export the software without a 
license, 

ReferctKra to the Export Adi^ 15 CFR chapter VII» 

subchapter CThey are issued by the United States r>pa 

and Security (BIS) under laws relating to the control of certain exports, reexports, and activities. 

- By downloading instiling or using the USPTO sun plied Software I am representing and 
^varxmitirig ihat 1 am not 1 ocated m, under the ^onSolot; or a national or resident of any country to 
which the export of the Software or related mfta nati on would be prohibited by the laws of the 
United States. At this time tliese countries fehideC^ 

This list reflecting the iirfbrmation in the Export Admmxstratiod Regulations Supplement No. 1 to 
Bart 740S page 7 and the other export cajntrol notification 
Treasury will be periodically updated on the EBC website. 

8. Availability 

I understand that the USPTO does not warrant or represent 1 00% availability of the USPTO Public Key 
Infrastructure services due to system maintenance, repair, or events outside the control of the USPTO, 
Information regarding scheduled downtixne, if known, will appear on the USPTO Electronic Business 
Center web site. Any delays caused by downtime must be addressed through the ordinary petition process. 

9. Term of Agreement 

This Agreement may be terminated by either party upon proper notice. In the case of a termination by the 
USPTO, notice may provided any reasonable means, indudinga posting on the USPTO website, 

18- General 

If any provision of this Agreement is declared by a court to be invalid, illegal, or unenfoceable, all other 
provisions shall remain in full ibrce and effect 

The USPTO reserves the right to refuse to issue certificates. The USPTO reserves the right to cancel this 
program at any tone. Modifications to this agn^ent will be posted on the USPTO website at 
.www.ust>to,gov/ebc/efe. Continued use of the system after posting will constitute agreement to the 
updated terms. 



(version^ April 2005) 
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H.RcqOeste 

Requests for issuance of cenifl<^t£^ inevocatkmof certi&^t^ or key recovery shall be sent to the USPTO 
Registration Authority at: 

Certificate Services Request 
US, Patent and Trademark Office 
Mail Stop EEC 
TO Box 1450 

Alesaadria, VA 22313-1450 
12- Dbpufe Resolution and Gover*«g Low 

This Agreement shall he governed by and construed in accordance with the laws of the United States of 
America. 



(vereiOT 30, April 2005) 
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